feat(android): implement deep link support for Android #19581
+92
−20
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jrainville
requested review from
a team,
caybro,
glitchminer,
micieslak and
osmaczko
and removed request for
a team
Member
Jenkins BuildsClick to see older builds (54)
|
jrainville
force-pushed
the
feat/android-deep-links
branch
from
157cd47 to
c5603fa
Compare
jrainville
force-pushed
the
feat/android-deep-links
branch
from
c5603fa to
af91799
Compare
Member
|
Fails to build DOtherside with: |
jrainville
force-pushed
the
feat/android-deep-links
branch
2 times, most recently
from
4e80a08 to
4f8fac9
Compare
jrainville
force-pushed
the
feat/android-deep-links
branch
from
4f8fac9 to
50dce40
Compare
micieslak
reviewed
Jan 14, 2026
Member
micieslak
left a comment
micieslak
left a comment
There was a problem hiding this comment.
I wonder if we could do that without altering StatusQActivity, in a bit more separated way. Ideally also without DOtherSide. We have https://github.com/status-im/MobileUI that I added some time ago to handle interoperability with native mobile APIs. Not sure if applicable here but probably worth checking.
alexjba
reviewed
Jan 15, 2026
| // Called from Qt via JNI when main window is visible | ||
| public static void hideSplashScreen() { | ||
| splashShouldHide.set(true); | ||
| userLoggedIn.set(true); |
Contributor
There was a problem hiding this comment.
If we need to track the logged in state it's probably not the best to do it here when the splash screen gets hidden, right? We could add a flag in the activity that's driven by qml/c++ to save the login state.
alexjba
reviewed
Jan 15, 2026
Contributor
alexjba
left a comment
alexjba
left a comment
There was a problem hiding this comment.
I wouldn't involve DOtherSide at all. I still hope we'll drop it in favor of seaqt and it would be nice to keep it clean.
An alternative would be to move the c++ implementation in StatusQ - for status specific, or MobileUI for generic android stuff.
Fixes #19562 Adds the needed manifest info to tell Android which links we supports. Then adds the Java code necessary to handle it. In this case, we listen to the Intent and if there is a URL, we emit an event that can be listened to in C++, which gets sent to the url_manager in Nim. Then we reuse the same code we already had.
jrainville
force-pushed
the
feat/android-deep-links
branch
from
50dce40 to
19a6053
Compare
Member
Author
|
@alexjba I tried to move the C++ code to MobileUI, but then it doesn't get found by the Java code: I think there is some linking change needed so that MobileUI functions can be called from Java. However, I don't have the knowledge or the time currently, with the fact that we want to cut this Friday and I currently use the Docker container to build Android locally, so it's very slow. I also renamed the |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does the PR do
Fixes #19562
Adds the needed manifest info to tell Android which links we supports.
Then adds the Java code necessary to handle it. In this case, we listen to the Intent and if there is a URL, we emit an event that can be listened to in C++, which gets sent to the url_manager in Nim. Then we reuse the same code we already had.
Affected areas
Architecture compliance
My PR is consistent with this document: QML Architecture Guidelines
Screencapture of the functionality
andrdoid-deep-links.webm
Impact on end user
Makes deep linking to the Status app work.
Reading the docs, if two apps support the same scheme, a drawer will be shown asking which app they choose to open, so all good.
How to test
Risk
Low